Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/mospf/mospf-minutes-90feb.txt

Text File | 1993-02-17 | 8.9 KB | 210 lines

CURRENT_MEETING_REPORT_


February 6, 1990 Held at Tallahassee IETF meeting Chaired in Steve's
absence by J. Moy/Proteon Minutes also written by J. Moy

MINUTES

This was the initial meeting of the MOSPF working group.  John Moy
presented a number of slides to introduce the subject of multicast
routing .  The slides also attempted to discuss the main areas where the
OSPF protocol needs to be changed/extended in order to provide multicast
support.

The slide discussion was broken up into the following areas:


   o o There was a short introduction into IP multicasting, including
     the Internet Group Management Protocol (IGMP, RFC 1112).  IGMP is
     responsible for maintaining host group membership.  Multicast
     routers must support IGMP (although in multicast OSPF only the
     Designated router will be actively sending/receiving IGMP
     messages).  Through using IGMP, a multicast router knows which
     multicast destinations are active on its attached LANs, but does
     not need to keep track of which particular hosts are requesting
     them (this is a considerable savings).
   o o A brief (and very incomplete) survey of multicast routing was
     attempted.  This was done through examination of Steve Deering's
     "Multicast routing in Internetworks and Extended LANs" paper.  This
     paper discusses a number of multicast routing methodologies:  an
     extension to the learning bridges to better support multicast, four
     separate Bellman-Ford multicast routing algorithms (arranged in
     order of increasing functionality and complexity) and a link-state
     multicast algorithm.  Finally, a mix of these approaches is
     explored for internet-wide multicast (and the wild-card multicast
     group is introduced).
     The most functional Bellman-Ford multicast algorithm in Steve's
     paper has been implemnted for BSD UNIX and is documented in RFC
     1075.
     It is expected that the multicast OSPF extensions will closely
     follow the link-state multicast algorithm in Steve's paper.
   o o The basic mechanism behind link-state multicasting was explored.
     A shortest-path tree is built having as root the multicast
     datagram's source.  Those branches not containing the specified
     multicast destination are then pruned.  This tree then yields the
     multicast datagram's path.
     At each hop, the multicast datagram is sent as a link-level
     multicast (or broadcast).  For this reason, multicast routers
     receive all multicast packets (i.e., must open up their multicast
     filters).
     The above trees are built on demand, and the results are cached
     (see below).

                                   1






o o Cache entries are used to store the results of the above SPF
  calculation.  For each tree built (there is potentially a different
  tree for each [source net, multicast destination] pair), a cache
  entry is formed.  The cache entry specifies the interface expected
  to receive the datagram, and the set of interfaces that the
  datagram should be forwarded out.
  Note that this proposed cache structure is slightly different than
  the one in Steve's paper.  First, it skips caching whole subtrees
  (implementation experience with OSPF shows that subtree caching is
  a lot of work), and it simplifies things by ignoring TTL.
  A separate tree (and a separate cache entry) will also possibly be
  calculated for each TOS value.  The entire cache must be cleared on
  topology changes.  When a group's membership changes, only cache
  entries pertaining to that destination need be flushed.
o o The changes and additions to the OSPF protocol are expected to be
  slight.  This is because OSPF already maintains a complete
  topological map of the routing domain, enabling the multicast tree
  calculation.  The expected changes to OSPF include the following:
  1) During the Dijkstra calculation, routing table entries (e.g.,
  for net X) will be marked with their corresponding "transit node".
  This node will be the root for multicast tree calculations having
  net X as datagram source.
o o Expected additions to OSPF include the following:  1) OSPF
  Designated Routers (DRs) will need to speak IGMP. 2) There will be
  a new link state advertisement (type 6) that routers will originate
  when there are multicast destinations on attached LANs.  There will
  be separate advertisements for each multicast destination.  These
  advertisements will be originated by DRs only.  This additional
  link state information will enable tree pruning.  3) There will
  probably be a new bit in the router links advertisement indicating
  "multicast-capable".  This allows some routers in the AS to decline
  multicast support.  4) The multicast tree calculation must be made
  deterministic; i.e., all routers must calculate the same tree in
  the presence of multiple equal-cost routes.
o o Inter-area multicast will be a little more complicated.  This is
  because when the datagram source is in another area, the local
  topology surrounding the source is hidden, inhibiting the multicast
  tree calculation.  In this case, we propose forming a tree for each
  of the other areas.  Each tree can be thought of as still being
  rooted at the datagram source; there will be a link from the
  datagram's source to each of the area's border routers.  The cost
  of these links will be that advertised by the area border routers
  in their summary link advertisements (note reverse direction).  The
  rest of the tree will (as in the intra-area case) deals only with
  the area's own topology.


                         datagram source
                                        :
                         ----------------
                         :    :    :    :
                         :    :    :    :
                        ABR  ABR  ABR  ABR
                         |    |         |

                                2






                                        -------
                                        |

     A multicast datagram enters the area through the border border
     routers.  The above scheme works only if area border routers are
     "wild-card" multicast receivers (i.e., receive all muticast
     packets).
     The logic for when the source of the datagram is exterior to the AS
     should be similar to the inter-area case.


The following questions were raised by the slides.  Bob Hinden asked
whether there were any estimates for the CPU usage consumed by the
potentially large number of tree calculations.  In a related question,
Chuck Davin wondered about the expected distribution of host group
memberships (e.g., number per LAN and lifetime).  These questions were
put off, hopefully for Steve Deering to answer.

Scott Brim questioned the behavior of the above inter-area multicasting
scheme in the presence of asymmetric paths.  He thought that there might
be the possibility of packet looping.  This issue should be looked into
further.

Besides the above, the following issues were brought up:


   o Should the multicast specification be written as a separate
     document, or should it simply depend on RFC 1131 (the OSPF
     specification)?
   o If we do not require all of the routers to be multicast-capable, is
     the possibility of reduced functionality acceptable?
   o How much backward compatibility should there be with the present
     OSPF protocol?
   o Should we try to be more efficient in inter-area multicasting, and
     drop the requirement that border routers be wild-card multicast
     receivers?


FUTURE MEETINGS

We intend to begin writing the specification for OSPF multicast
extensions.  This will be done primarily through communications on the
mospf mailing list ([e-mail]).

There will be a MOSPF WG meeting at the next IETF (Pittsburgh).  Also,
if enough progress is made between meeting, we will attempt to schedule
the teleconferencing facilities.

ATTENDEES


    John Cavanaugh           [e-mail]

                                   3






Rob Coltun               [e-mail]
Samir K. Chatterjee      [e-mail]
George Clapp             meritec![e-mail]
Daniel Kellen            [e-mail]
Stan Froyd               [e-mail]
James R. Davin           [e-mail]
Douglas Bagnall          [e-mail]
Metin Feridun            [e-mail]
Tom Easterday            [e-mail]
Ballard Bare             [e-mail]
Cathy Aronson            [e-mail]
Bob Hinden               [e-mail]
Frank Solensky           [e-mail]
Dave Miller              [e-mail]
Tim Seaver               [e-mail]
Joel Replogle            [e-mail]
Tony Mason               [e-mail]
Farokh Deboo             [e-mail]
Dino Farinacci           [e-mail]
Jeffrey Burgan           [e-mail]
Dave O'Leary             [e-mail]



                               4